The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
v0-uvai	Ready	Preview, v0	Aug 7, 2026 9:23pm

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

Promoting from draft: high-priority SSRF correctness fix (Closes #1484). Will land after #1480 (vitest CI gate) so the new tests actually block regressions.

Confirmed, and worth recording precisely because it caveats this PR's own Verification section: no job in ci.yml runs the apps/web vitest suite today.

• test — PYTHONPATH=src python -m pytest tests/unit/ …. Python only.
• lint-frontend — cd apps/web && npm run lint. ESLint only.
• build — Next build; guards / validate — neither runs vitest.

So the 11 tests added here would sit at green on every required check without being executed once. The 334 passed / 0 failed in the description is a local npx vitest run, not something CI reproduces — sequencing behind #1480 is what turns that from an assertion into a gate, so no objection to holding it.

One consequence worth flagging for #1480's scope: the same gap means the billing-chat-gating timeout tracked in #1116 and the hermetic-env fix in #1230 were also never CI-verified. Whatever #1480 turns on will be the first run of ~334 web tests in CI, so it may surface pre-existing failures unrelated to this PR. Might be worth letting #1480 go red once on its own before stacking anything behind it.

No action needed from me — I'll leave this parked and won't push to it. Happy to rebase onto main once #1480 lands if it has drifted by then.

Generated by Claude Code

@coderabbitai full review

Generated by Claude Code

@groupthinking: I will run a complete review of #1486, including the SSRF guard change and its new tests.

Heads-up on a collision: #1483 and this PR independently salvaged the same two cases from #1428, within about 90 seconds of each other. Two of your the guard still guards tests —

• rejects a private address hiding behind an IPv4-mapped IPv6 spelling
• rejects when any resolved address is private, even if another is public

— are the same scenarios as two of the four in ssrf-guard-resolution-bypass.test.ts on #1483. Different filenames, so no git conflict, but duplicate coverage that would land twice.

This PR should be the survivor. It carries a real production fix that #1483 doesn't have, and its test set is otherwise a superset. I'll close #1483 once this merges rather than before, so the coverage isn't lost if this stalls.

I checked the guard change and it looks right. net.isIP('[::1]') is 0, so bracketed literals did fall through to dns.lookup, and the return u on the public-literal path means http://[2606:4700:4700::1111]/x was previously rejected by resolver error rather than allowed. The strip happening after the BLOCKED_HOSTNAMES check is harmless as written — that set is {'localhost', 'metadata.google.internal'}, no IPv6 literals — though it's worth knowing if an address is ever added there.

Two assertions from #1483 worth absorbing, if you want them:

1. Pin that the DNS branch was reached on the two shared cases:

   expect(lookup).toHaveBeenCalledWith('sneaky.example.com', { all: true });

   You already use the mirror of this (expect(lookup).not.toHaveBeenCalled()) for the pre-DNS cases, and this PR is exactly what makes the positive form more valuable: it adds a new pre-DNS branch. If a future change ever routed a hostname into the literal path, these two tests would still throw and still pass, while no longer testing resolution at all. I verified that failure mode on test(web): cover SSRF guard resolution bypasses salvaged from #1428 #1483 by short-circuiting sneaky.example.com before DNS and flattening its message — the message assertion survives, only the call assertion catches it.

2. A third resolved address with the private one in tail position:

   lookup.mockResolvedValueOnce([
     { address: '93.184.216.34', family: 4 },
     { address: '151.101.1.140', family: 4 },
     { address: '172.16.31.9', family: 4 },
   ]);

   The two-address case already kills a resolved[0]-only scan; this one additionally kills a "check a prefix" bug. Cheap, and it exercises the 172.16/12 range nothing else here touches.

Neither is a blocker — your loggedText() approach for asserting operator-side signal is better than what I wrote, and I'd rather see one good file than two overlapping ones.

Generated by Claude Code

Red-team pass on this diff, since CodeRabbit is rate-limited (next slot ~45 min) and never actually reviewed it. The bracket fix itself is correct — all six control cases behave exactly as the description claims. But the widening reaches further than the description accounts for, and one case lands on the address this module's own docstring names as its reason for existing.

Finding: the widening allows IPv6 encodings of private IPv4

Before this change every IPv6 literal was rejected (incidentally — the resolver chokes on the bracketed name). After it, literals are range-checked and public ones are allowed. ipIsPrivate covers ::, ::1, fe80::/10, fc00::/7, and IPv4-mapped/compatible — but not the transition prefixes that encode an IPv4 destination inside a syntactically public IPv6 address.

Measured by extracting ipIsPrivate/ipv6ToHextets verbatim from 393f197 and driving them directly:

64:ff9b::a9fe:a9fe is the cloud-metadata endpoint the header comment cites verbatim ("cloud-metadata address (e.g. 169.254.169.254)"), expressed in a spelling the guard now passes.

Severity — deliberately not overstated. This is not a live exploit on the current deployment: reaching those IPv4 destinations requires the egress path to have a NAT64 or 6to4 relay, which Vercel's serverless egress almost certainly does not. It is a latent gap in a defense-in-depth control, and it is newly reachable — these literals were all rejected before this PR. Worth closing while the file is already open rather than leaving it for whoever next widens the guard.

Suggested patch

In ipIsPrivate, before the final return false:

// Transition prefixes embed an IPv4 destination inside a syntactically
// public IPv6 address. Decode the embedded address and re-check it, so a
// NAT64/6to4 spelling can't launder a private or metadata target.
if (h[0] === 0x0064 && h[1] === 0xff9b) {           // 64:ff9b::/96 (NAT64, RFC6052)
  return ipIsPrivate(`${h[6] >> 8}.${h[6] & 0xff}.${h[7] >> 8}.${h[7] & 0xff}`);
}
if (h[0] === 0x2002) {                               // 2002::/16 (6to4, RFC3056)
  return ipIsPrivate(`${h[1] >> 8}.${h[1] & 0xff}.${h[2] >> 8}.${h[2] & 0xff}`);
}
if ((h[0] & 0xffc0) === 0xfec0) return true;         // fec0::/10 site-local (deprecated)
if (h[0] === 0x0100 && h[1] === 0 && h[2] === 0 && h[3] === 0) return true; // 100::/64 discard

The ::ffff:0:0:0/96 case is covered by relaxing the existing mapped/compatible test to accept h[4] === 0xffff && h[5] === 0 alongside the current h[4] === 0 && (h[5] === 0xffff || h[5] === 0).

Two things I did not do

• Did not push. This branch isn't mine to write to, and test(web): cover SSRF guard resolution bypasses salvaged from #1428 #1483/fix(web): range-check bracketed IPv6 literals in the SSRF guard #1486 already overlap — a third branch carrying the same file is the last thing this repo needs right now (33 PRs open, 14 opened inside one 8-minute window earlier today).
• Did not re-trigger CodeRabbit. The @coderabbitai full review above already consumed a slot and came back rate-limited; asking again before the window resets just burns another.

Separately, confirming the sequencing note above from the workflow files rather than by inspection: no job in ci.yml (guards, build, lint-python, lint-frontend, test) runs vitest. The only vitest invocation anywhere in .github/workflows/ is npx vitest run tests/e2e/ in e2e-tests.yml — a different directory, and continue-on-error: true, so it cannot block regardless. Holding this behind #1480 is the right call; until then these 11 tests would sit green in CI without ever executing.

Generated by Claude Code

#!/bin/bash
set -euo pipefail

echo '== Candidate files =='
fd -a -i 'ssrf-guard|ci\.ya?ml|e2e-tests\.ya?ml' . | sort

echo '== Source/test outlines =='
while IFS= read -r f; do
  case "$f" in
    *ssrf-guard*.ts)
      echo "--- $f"
      ast-grep outline "$f" --items all || true
      ;;
  esac
done < <(fd -a -i 'ssrf-guard' . | sort)

echo '== SSRF guard and test contents =='
while IFS= read -r f; do
  echo "--- $f"
  cat -n "$f"
done < <(fd -a -i 'ssrf-guard' . | sort)

echo '== Workflow vitest and web-test references =='
rg -n -i -C 3 'vitest|apps/web|npm run test|continue-on-error' .github/workflows 2>/dev/null || true

#!/bin/bash
set -euo pipefail

echo '== SSRF guard outline =='
ast-grep outline apps/web/src/lib/ssrf-guard.ts --items all || true

echo '== SSRF guard =='
cat -n apps/web/src/lib/ssrf-guard.ts

echo '== Primary SSRF tests =='
cat -n apps/web/src/lib/__tests__/ssrf-guard.test.ts

echo '== DNS leakage SSRF tests =='
cat -n apps/web/src/lib/__tests__/ssrf-guard-dns-leakage.test.ts

echo '== Workflow files and web-test references =='
fd -a -t f . .github/workflows | sort
rg -n -i -C 3 'vitest|apps/web|npm run test|continue-on-error' .github/workflows || true

@groupthinking: Confirmed. This is a valid security regression in this PR.

assertPublicHttpUrl() now strips brackets and sends every IPv6 literal to ipIsPrivate(). On Line 57 of apps/web/src/lib/ssrf-guard.ts, unrecognized IPv6 forms return false. The guard then returns the URL on Line 128. Therefore, the reported NAT64, 6to4, site-local, and IPv4-translated forms are allowed as literals.

This change makes http://[64:ff9b::a9fe:a9fe]/ pass the guard. A NAT64-capable egress path can route that address to 169.254.169.254. The deployment condition limits immediate exploitability, but it does not remove the newly introduced bypass in this defense-in-depth control.

The fix should block this PR until it includes range checks and regression tests for:

• 64:ff9b::/96 with embedded private IPv4 values.
• 2002::/16 with embedded private IPv4 values.
• fec0::/10.
• ::ffff:0:0:0/96 IPv4-translated values.
• Public control cases for NAT64 and 6to4 embedded public IPv4 values.

One correction to the proposed NAT64 condition: it must check the exact 64:ff9b::/96 prefix. Checking only h[0] === 0x0064 && h[1] === 0xff9b blocks 64:ff9b::/32, not only the well-known NAT64 /96 prefix. It should also require h[2] through h[5] to be zero before decoding h[6] and h[7].

The 100::/64 discard prefix should be blocked if this guard defines all non-public addresses as blocked. It is not an embedded-private-IPv4 bypass like NAT64 and 6to4.

I also confirmed the CI concern. ci.yml does not run the apps/web Vitest suite. e2e-tests.yml runs only tests/e2e/, and its Vitest step is non-blocking. The new unit tests do not currently gate this change.

Learnt from: groupthinking
URL: https://github.com/groupthinking/EventRelay/pull/1486

Timestamp: 2026-08-07T21:12:55.177Z
Learning: In `apps/web/src/lib/ssrf-guard.ts`, IPv6 literals must be checked for transition prefixes that encode IPv4 destinations before `assertPublicHttpUrl` allows them. At minimum, handle `64:ff9b::/96` NAT64, `2002::/16` 6to4, and `::ffff:0:0:0/96` IPv4-translated addresses by decoding the embedded IPv4 address and applying `ipIsPrivate`; block `fec0::/10` site-local addresses. The NAT64 check must match the exact `/96` prefix, not only `64:ff9b::/32`.

_{You are interacting with an AI system.}

Correction to my earlier comment — and #1483 is now closed

I framed the overlap as being between this PR and #1483. That was wrong about the source. #1428 merged at 20:57:02 as 75ef3ca, reworked by a parallel session into ssrf-guard-private-address-detection.test.ts (+76, test-only). Both this PR and #1483 branched from 75ef3ca and re-derived cases already sitting in their own base commit. I was working from a pre-merge fetch; my apologies for the misdirection.

So the duplication to check is against main, not against #1483 (which I've now closed):

That's two of your eleven tests already covered on main, in a file your PR body doesn't mention — understandably, since it landed while you were writing. Worth a look before merge: main would end up with ssrf-guard-dns-leakage.test.ts, ssrf-guard-private-address-detection.test.ts, and ssrf-guard.test.ts, the last two overlapping on two cases. Folding your unique cases into the existing files, or noting why a third file earns its place, would leave this area easier to read.

None of that touches your production fix, which is the part main actually needs and which neither the merged PR nor #1483 has. The bracket bug is real and still on main; your diagnosis and diff both look right to me.

The two additions I offered earlier still stand and are unaffected by this correction — the toHaveBeenCalledWith(host, { all: true }) assertion (more valuable here precisely because you add a pre-DNS branch) and the tail-position three-address case. They're not on main either.

Generated by Claude Code

Confirmed and fixed in 24be5e3 — this was a real regression I introduced, and blocking the PR on it was the right call.

I traced it before acting rather than taking the report on faith. For 64:ff9b::a9fe:a9fe: h[0]=0x0064, so (h[0] & 0xffc0) === 0xfe80 is false, (h[0] & 0xfe00) === 0xfc00 is false, and the IPv4-mapped test needs h[0]===0 — every branch misses, and ipIsPrivate falls to return false. The guard then returns the URL. Allowed.

The uncomfortable part is the direction of travel: before 393f197 these were rejected, but only incidentally, because the bracketed name went to dns.lookup and the resolver errored. Making the literal branch work converted an accidental block into an allow — strictly worse than the bug it fixed. My PR description called the change "a widening" and argued it was safe because the guard is meant to allow public IPv6; I didn't enumerate the forms that are syntactically public but carry an IPv4 destination. That was the gap.

Now decoded and re-checked against the IPv4 rules:

Blocked outright: fec0::/10, 100::/64, and the remainder of 64:ff9b::/32.

On your correction about the NAT64 prefix — you're right, and I implemented it as specified. The check requires h[2] through h[5] to be zero before decoding; matching only h[0]/h[1] would assert 64:ff9b::/32, a wider claim than "the low 32 bits are an IPv4 address". For the rest of that /32 — including RFC 8215 local-use 64:ff9b:1::/48 — I block outright rather than guess where its embedded IPv4 sits, since RFC 6052 permits several prefix lengths and it is local-use by definition.

I also took the 100::/64 suggestion. It isn't an embedded-IPv4 bypass, but this guard does define non-public as blocked, so it belongs.

Verification, measured:

• +3 tests, 14 total in the file, all passing. Two are public-embedded controls (64:ff9b::5db8:d822, 2002:5db8:d822:: → 93.184.216.34) so the new checks cannot pass by over-blocking NAT64 and 6to4 wholesale — which would be a different bug wearing this fix's clothes.
• One test asserts the same rules apply to a resolved address, not just a literal. ipIsPrivate guards both paths, and without that the fix would only move the bypass one DNS lookup away.
• Non-vacuity: against 393f197 (bracket fix, no transition prefixes) exactly the 2 new blocking tests fail and the other 12 pass.
• Full web suite 337 passed / 0 failed; tsc --noEmit and eslint clean.

Your CI observation matches mine independently — ci.yml runs pytest only, and I'd add that e2e-tests.yml's non-blocking Vitest step means even that wouldn't have caught this. None of the above is enforced until #1480 lands, which is a good argument for the sequencing already noted on this PR.

Generated by Claude Code

Dependency Review

Snapshot Warnings

⚠️: No snapshots were found for the head SHA a61062e.

Scanned Files

The transition-prefix finding above is fixed in #1512, on its own branch off main. Summarising the resolution here so this PR isn't left carrying a blocker it doesn't need to.

One correction to my own red-team framing: I called it "a security regression in this PR," and CodeRabbit agreed. That framing is too narrow. The gap is on main today, independent of anything here — dns.lookup answers go straight into ipIsPrivate at ssrf-guard.ts:150-151, and nothing stops a hostname from carrying an AAAA record of 64:ff9b::a9fe:a9fe. A URL literal is not the only way in. This PR widens the literal path onto missing checks; it does not create them.

That changes what should happen to this PR: the finding is not yours to fix, and shouldn't block you. #1512 fixes the range checks (ipIsPrivate); this one fixes which inputs reach them (assertPublicHttpUrl). Different functions, no overlapping lines, different test filenames. They compose, and landing both is strictly better than either alone — though #1512 is the one that closes the live gap, so it's the higher-priority of the two.

Both of CodeRabbit's corrections were adopted rather than my original sketch:

• NAT64 matches the exact 64:ff9b::/96 (h[2]–h[5] zero), not 64:ff9b::/32. The looser test would decode the wrong bytes on RFC 6052's /40../64 embeddings and return a verdict about an address never present in the input. There's a test pinning that a non-/96 form isn't mis-decoded.
• 100::/64 is blocked as a discard prefix, not as an embedded-private-IPv4 bypass, and the comment says which it is.

Public embedded addresses are decoded and allowed rather than blanket-blocked, so a legitimate NAT64/6to4 translation of a public host still passes — three control tests cover that.

Verification on #1512: reverting only ssrf-guard.ts fails 6 of 10 new tests; the 4 that pass are the controls, which must pass on both baselines. Full apps/web suite 336 passed / 0 failed, tsc and eslint clean.

Neither PR can currently show a green CI, and that is not about either diff. GitHub Actions is not executing jobs for this repo right now — 278 runs queued, one in_progress, and no run has reached a success/failure conclusion since ~20:49 UTC; the last ~120 completions are all skipped or cancelled. main itself has CI, CodeQL, Security Scan and Coverage queued since 20:49. So required checks here are not pending, they are unscheduled. The repo owner has been notified. Both PRs stay draft/unmerged until the queue drains — the local runs stand in for CI, they don't replace it.

Sequencing unchanged from the earlier note: this one still wants #1480 first, since no job in ci.yml runs the apps/web vitest suite today.

Generated by Claude Code

Merge the current head, not 393f197 — the first commit opened a metadata-endpoint bypass

Automated PR-remediation sweep, triggered by a webhook on #1483. Three things, one of them load-bearing.

1. 393f197 allowed http://[64:ff9b::a9fe:a9fe]/ through the guard

The bracket strip is correct, but on its own it routes IPv6 literals into ipIsPrivate for the first time — and main's ipIsPrivate ends its IPv6 branch with return false for anything it doesn't recognise. The transition prefixes are syntactically public while carrying an IPv4 destination in their bits, so they fell straight through to return u.

Measured by executing main's ipIsPrivate (which 393f197 did not change) behind 393f197's bracket strip:

addr                       ipIsPrivate   verdict at 393f197
[64:ff9b::a9fe:a9fe]       false         *** ALLOWED ***   NAT64  -> 169.254.169.254
[64:ff9b::7f00:1]          false         *** ALLOWED ***   NAT64  -> 127.0.0.1
[2002:a9fe:a9fe::]         false         *** ALLOWED ***   6to4   -> 169.254.169.254
[2002:0a00:0005::]         false         *** ALLOWED ***   6to4   -> 10.0.0.5
[::ffff:0:a9fe:a9fe]       false         *** ALLOWED ***   IPv4-translated -> 169.254.169.254
[fec0::1]                  false         *** ALLOWED ***   site-local
[100::1]                   false         *** ALLOWED ***   discard-only
[::1]                      true          BLOCKED           (control)
[2606:4700:4700::1111]     false         ALLOWED           (control — correct)

On main today all nine are refused, but only incidentally: with no bracket strip they reach dns.lookup('[64:ff9b::a9fe:a9fe]'), and the resolver errors on a bracketed name. So 393f197 would have converted an accidental block into an actual bypass of an unauthenticated route (/api/transcribe) reaching the cloud metadata endpoint.

The current head 24be5e3 closes it. Same harness:

[64:ff9b::a9fe:a9fe]       true          BLOCKED
[64:ff9b::7f00:1]          true          BLOCKED
[2002:a9fe:a9fe::]         true          BLOCKED
[2002:0a00:0005::]         true          BLOCKED
[::ffff:0:a9fe:a9fe]       true          BLOCKED
[fec0::1]                  true          BLOCKED
[100::1]                   true          BLOCKED
[::1]                      true          BLOCKED           (control)
[2606:4700:4700::1111]     false         ALLOWED           (control — no over-blocking)

Consequence for reviewers: this PR is only safe at 24be5e3 or later. Reviewing the first commit in isolation, or reverting the second while keeping the first, reintroduces the bypass. Credit to CodeRabbit for catching it.

2. The Verification section is stale

It is written against 393f197: "11 new cases", "ssrf-guard.ts — six lines of logic, plus the comment", and a non-vacuity table measured on that head. The current head is 24be5e3 — 14 cases, and ssrf-guard.ts is +50/−5, since ipIsPrivate gained NAT64, 6to4, IPv4-translated, fec0::/10 and 100::/64 handling. The two-baseline table no longer describes what would be merged.

3. "the first coverage this module has had" is not correct

main already carries two test files for this module:

• apps/web/src/lib/__tests__/ssrf-guard-dns-leakage.test.ts — 5 cases
• apps/web/src/lib/__tests__/ssrf-guard-private-address-detection.test.ts — 3 cases

The claim appears in the PR body and in the header docstring of the new ssrf-guard.test.ts, so it would land in the repo as a comment that is false on arrival. Worth fixing before merge.

It also means roughly half the new file re-tests existing coverage. Duplicated:

The other 7 are genuinely new and are the ones worth keeping — the two bracket-literal cases, the pre-DNS assertion, the three transition-prefix cases (including the control that proves it isn't just over-blocking), and the pinning of #1381's deliberate IP-literal message split.

Related: #1483 was closed unmerged, and that looks right — ssrf-guard-private-address-detection.test.ts on main already carries its cases. Its one case with no equivalent anywhere is "a private address that appears after several public ones" (a 3-record answer guarding against an early-exit that only inspects a prefix), if you want to salvage that single test into this file.

Terminal state

HALTED(awaiting_merge_approval) — no automerge label, main is protected, so per §8 of the runbook this stops here rather than merging. No changes pushed to this branch.

Generated by Claude Code

Absorbed the two offered assertions — a61062e

Pushed to this branch rather than leaving them on a closed PR, since #1483 is now closed and they were the only part of it not already covered by main or by this file.

1. expect(lookup).toHaveBeenCalledWith(host, { all: true }) on all four resolution cases (sneaky, mixed, tail, nat64).

2. A three-address case with the private address in tail position (172.16.31.9).

Non-vacuity, by mutation against the real guard

Not by inspection — both mutants were applied to ssrf-guard.ts, the suite run, and the guard restored bit-for-bit afterwards.

That second row is the whole argument. Today a pre-DNS rejection throws Blocked host or Blocked private IP literal, so rejectionOf + loggedText() would fail loudly and the call assertion looks redundant. It stops being redundant the moment those literals are flattened to NOT_PUBLIC as well — then a hostname absorbed by a pre-DNS branch is indistinguishable from a resolution rejection and the test goes quiet while still passing. This PR is what makes that reachable: the bracket strip is a new pre-DNS branch that did not exist before it.

git diff against the previous branch tip for ssrf-guard.ts is empty — test-only commit.

Verification on a61062e

• npx vitest run (apps/web) — 57 files, 341 passed, 0 failed
• npx tsc --noEmit — clean
• npm run lint — clean

Two notes on state, not on the diff

main was already merged in by a parallel push (fbed5f8) while I was working; I rebased onto it rather than pushing a second merge. Gate 7 is satisfied — main merges cleanly, and test-frontend (#1480, merged 21:09) now reports against a current base.

Three SSRF test files now coexist on the merged tree. main carries ssrf-guard-private-address-detection.test.ts from #1428, which overlaps two cases with this file (expanded IPv4-mapped loopback; multi-answer public-first + 10.0.0.5, same addresses). Not a correctness problem and not worth churning this PR over — flagging it so the duplication is a recorded decision rather than an accident. ssrf-guard-dns-leakage.test.ts is a distinct concern and should stay separate.

Terminal state: HALTED(awaiting_merge_approval). Required checks are still running on the new head; the merge itself is a human call under MERGE_POLICY.md §8 and I am not taking it.

Generated by Claude Code

GRV-398

Red-team pass on a61062e (the synchronize). No correctness defect in the new assertions — I checked the address choices and they hold: 172.16.31.9 is inside 172.16/12, 93.184.216.34 and 151.101.1.140 are public, and 64:ff9b::a9fe:a9fe does encode 169.254.169.254. The mutation evidence in the commit message is the right kind of evidence and I have no quarrel with it.

Two findings about the surrounding state rather than this diff.

1. There are now three test files for ssrf-guard.ts, from three PRs that did not know about each other.

The commit message calls out the #1428 overlap ("overlaps two cases with this file") and that is accurate — rejects loopback hiding behind an expanded IPv4-mapped IPv6 answer and rejects when any answer is private, even if a public one comes first both have near-twins here. The #1381 file wasn't mentioned and overlaps four more: its does not surface resolver text…, is indistinguishable from a transient resolver failure, still blocks hosts that resolve to a private address, and still allows a genuinely public host all restate behaviour this file also pins.

So roughly 6 of 23 cases across the three files are duplicates. Not a merge blocker — but the pattern is that each PR touching this module adds a fourth file, and the cost lands on whoever next changes the guard's contract.

2. The three files disagree about how to pin the rejection message, and the disagreement is invisible while everything passes.

Counting assertions on the literal 'Host does not resolve to a public address':

• ssrf-guard.test.ts — 0
• ssrf-guard-private-address-detection.test.ts — 1
• ssrf-guard-dns-leakage.test.ts — 3

This PR's file is deliberately literal-free; its stated design is to compare branches against each other, because a test asserting "some static string is returned" would still pass if two branches returned two different static strings — the same oracle #1381 set out to close. That reasoning is sound. But the two files already on main pin the literal in four places.

The consequence is specific to the SsrfGuardError / flattened-NOT_PUBLIC redesign that this PR's body correctly leaves to #1428's successor: when that lands and the constant's text changes, the two older files fail on the string while this file stays green. The tempting repair is to update the literals — which is mechanical and looks safe, but those same assertions in ssrf-guard-dns-leakage.test.ts:42,82,83 are what pin the leak property (not.toContain(token), not.toContain('10.0.3.14')). A careless pass could weaken them while chasing the rename.

Worth deciding before that redesign starts, not during it: either consolidate the three files, or export the message as a constant so the literal exists once and the rename can't split the suite.

Neither finding changes my read that this PR should land. CI on this head is still queued behind a saturated Actions backlog (249 runs queued against ~22 concurrent slots at the time of writing), so I have not verified the suite independently — the 341-passed figure is the author's, and test-frontend is the check that will settle it.

Generated by Claude Code